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Project  summary 


The  project  focuses  on  architectural  and  protocol  techniques  for  multicast  trans¬ 
port  of  data  in  the  evolving  applications  (such  as  video,  audio  £ind  graphics).  The 
techniques  allow  creating  a  ‘programmable  network’  that  may  be  ‘plugged-in’  with 
QOS  and  flow  parameters  of  data  streams  to  instantiate  the  network  behavior  for 
matching  the  needs  of  each  application.  The  ‘programmability’  of  the  network  can 
allow  reducing  the  deployment  of  communication  resources  (such  as  bandwidth)  for 
supporting  applications.  This  philosophy  is  in  alignment  with  the  evolving  ‘Internet 
Service  Layer’  functionalities.  A  canonical  network  substrate  so  created  may  then 
be  employed  to  construct  multicast  transport  services. 

A  tree-structured  chaimel  in  the  network  is  used  as  building  block  for  realizing  mul¬ 
ticast  data  transport.  Data  from  different  sources  are  multiplexed  over  a  shared  tree 
channel  for  reaching  destinations  through  intermediate  network  nodes  and  links. 
The  sharing  of  segments  across  multiple  data  streams  allows  reducing  the  overall 
fixed  costs  of  maintaining  ‘connections’  in  the  backbone  network,  and  also  offers  the 
potential  for  reduced  bandwidth  allocation  for  bursty  data  flows  due  to  ‘statistical 
multiplexing’  of  these  flows. 

We  developed  resource  allocation  protocols  and  routing  algorithms  for  midticast 
networks,  based  on  shared  tree  channels.  The  protocols  were  evaluated  by  ‘modeling’ 
and  ‘experimentation’  activities  on  LANs  and  the  ATM-based  testbed  NYNET  at 
Rome  Laboratory.  Applications  involving  the  distribution  of  video  and  audio  data 
were  developed  to  demonstrate  the  viability  of  the  multicast  network  technology. 

Major  uses  of  the  project  will  be  in  ‘Integrated  Service  Networks’  that  are  becoming 
the  basis  for  Distributed  Information  Environments:  in  both  military  and 
civilian  applications. 
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1  Project  motivation  and  direction 


There  has  been  an  increasing  need  to  deliver  digital  subscriber  services  of  diverse 
characteristics  and  features  to  subscriber  terminals  (e.g.,  digital  TV,  video  conferenc¬ 
ing,  distributed  computing)  through  a  wide-area  and/or  a  metropolitan  area  network. 
Applications  involving  the  distribution  of  visual  stiU  images,  video  sequences  and  an¬ 
imated  scientific  visualizations  have  begim  to  dominate  the  transport  load  offerings 
on  the  network.  One  of  the  functional  capabilities  required  of  such  a  multi-service 
network  is  data  multicasting,  i.e.,  dispatching  a  data  on  one  or  more  links  of  a  network 
node  (or  switch),  for  multi-destination  delivery.  The  multicast  capability  should  be 
provided  at  multi-megabit  data  rates,  such  as  10-15  mbfsec  for  compressed  video  and 
100  mb! sec  for  composite  imaging.  Furthermore,  the  data  transport  requirements 
of  the  evolving  applications  are  becoming  more  diverse,  expecting  different  levels  of 
data  delivery  guarantees  from  the  network.  Such  requirements,  often  prescribed  as 
a  quality  of  service  (QOS),  include  timely  delivery  of  data  such  as  video  and  audio, 
and  a  guaranteed  bandwidth  to  sustain  a  certain  trcinsfer  rate  such  as  live  video 
images.  See  Figure  1.  The  multicasting  requires  network  level  support  whereby  the 
data  from  a  source  entity  are  transported  through  multiple  network  paths  towards 
destination  entities,  while  meeting  the  application  level  QOS  requirements. 

Requirements  of  multicast  networks 

In  light  of  the  evolution  of  diverse  applications  on  one  hand  and  that  of  backbone 
network  technologies  (such  as  ‘ATM  cell  switching’  based  fiber  networks,  intercon¬ 
nected  ‘packet  switching’  LANs/wireless  networks  and  high  level  ‘frame  switching’ 
networks)  on  the  other  hand,  it  is  essential  that  the  support  of  multicast  functions 
by  a  switching  system  meets  the  following  requirements: 

•  Provide  uniform  set  of  mechanisms  to  transport  the  data  of  diverse  applications 
over  a  backbone  network; 

•  Allow  scalable  implementation  of  applications  on  a  variety  of  backbone  net¬ 
works; 

•  Be  usable  in  an  environment  where  heterogeneous  backbone  networks  may 
co-exist; 

•  Be  extensible  to  allow  smooth  introduction  of  newer  applications  and  backbone 
network  technologies. 
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Figure  1:  Multi-destination  data  delivery  in  a  multi-service  network 


In  this  R  &  D  contract  undertaken  for  the  Rome  Laboratory,  we  investigated  the 
issues  in  providing  generic  multicast  models  to  meet  the  above  requirements  and 
generating  flexible  transport  architectures  that  incorporate  the  models.  These  archi¬ 
tectures  Me  amenable  for  realization  on  a  variety  of  high  speed  backbone  networks. 

Are  existing  communication  models  suitable  ?? 

There  are  three  aspects  of  a  given  multicast  model  that  determine  the  flexibility, 
extensibility  and  scalability  of  networks  implemented  using  the  model  to  support 
multi-service  applications  (see  Figure  2): 

•  Richness  of  multicast  service  interface  provided  by  the  model 

Typically,  the  multicast  interface  should  allow  the  user  entities  to  specify 
transport  attributes  of  data,  viz.,  quality  of  transport  service  (QOS),  such 
as  transfer  rates,  burstiness  and  acceptable  end-to-end  delays  for  any  t3rpe 
of  application  in  a  uniform  manner.  It  should  also  allow  any  arbitrary  set 
of  destinations  to  be  selected  for  data  delivery  (e.g.,  private  discussion 
groups  in  a  video  conference). 

•  Adaptability  of  architectmal  components  of  the  model  to  backbone  networks 

The  communication  architecture  of  the  model  should  be  embeddable  onto  zmy 
type  of  target  backbone  network.  To  allow  this,  the  layer  functions  and 
the  inter-layer  boundaries  in  the  architecture  should  be  weU-specified  so 
that  they  can  be  appropriately  mapped  to  the  target  network  layers.  For 
instance,  how  a  global  multicast  supported  by  the  model  interworks  with 
the  native  multicast  facility  available  in  backbone  networks  (e.g.,  LANs) 
should  be  concretely  specifled. 

•  Compatibility  of  protocol  elements  supported  by  the  model 
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Figure  2:  Functional  requirements  of  multicast  models  and  their  mapping  to  target 
networks 

The  protocol  elements  used  to  realize  the  model  should  be  mappable  onto 
the  protocols  supported  in  the  target  network.  For  instance,  the  ‘source¬ 
routing’  of  packets  as  allowed  in  the  model  (say)  should  be  supported  by 
a  ‘backbone  adaptation  layer’  that  allows  variable  length  packet  headers. 

A  model  that  is  not  comprehensive  enough  to  support  all  these  aspects  is  deemed 
restrictive  in  its  usability  in  implementing  multi-service  networks. 

Many  network  models  that  evolved  in  the  ARPANET,  OSI  and  telephone  network 
worlds  do  not  meet  the  above  requirements.  For  instance,  a  packet  transport  over 
point-to-point  paths  set  up  between  each  destination  and  the  source  as  allowed  by 
OSI  network  layer  standards  [1]  may  cause  a  packet  to  be  sent  more  than  once  over  a 
link  shared  between  the  various  paths,  thereby  entailing  wastage  of  link  bandwidth. 
Likewise,  the  IP  ‘host  group’  model  for  internet  multicasting  [2]  is  usable  only  in 
IP  based  networks.  Though  Deering’s  earlier  work  on  multicasting  provides  many 
features  [3],  it  does  not  eiUow  user  level  specification  of  QOS  to  be  supported  by  the 
network.  We  shall  provide  more  concrete  comparisons  with  existing  models  later  in 
the  report. 

Thus  it  is  necessary  to  provide  a  comprehensive  model  of  multicasting  meeting  aU 
the  requirements  stated  earlier. 

Focus  of  project  activities 


We  adopted  the  ‘proof-of-concept  by  modeling  and  experimentation’  to  substanti¬ 
ate  the  key  ideas  in  the  project.  The  ‘modeling’  component  of  work  involved  the 
generation  of  ceuionical  network  architectures  and  service  paradigms,  and  develop- 
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ment  of  simple  prototypes  of  these  architectures  on  a  small  Ethernet  LAN-based 
testbed  at  Kansas  State  University.  The  ‘experimentation’  component  of  the  project 
involved  implementing  the  models  on  the  ATM-based  NYNET  testbed  at  the  Rome 
Laboratory.  The  2-tier  approach  separated  the  ‘modeling’  and  ‘experimentation’ 
components,  with  the  concepts  generated  by  the  former  validated  by  the  latter. 

The  Statement  of  Work  phrases  attached  to  the  contract  with  Rome  Labora¬ 
tory  were  used  to  set  the  ‘direction’  of  this  project.  The  ‘statement  of  work’,  in 
a  larger  context,  directs  the  project  towards  developing  a  technology  to  support  a 
Distributed  Information  Environment  for  use  by  civilian  and/or  military  ap¬ 
plications. 


Organization  of  report 

Section  2  identifies  the  basic  ingredients  required  of  multicast  transport  architectures 
for  supporting  multi-service  applications.  Using  these  requirements  as  guidelines, 
section  3  describes  an  architecture  developed  in  this  project  to  support  QOS  and 
flow  specifications,  and  compares  it  with  currently  available  architectures.  Section 
4  describes  the  canonical  functional  elements  incorporatable  into  the  various  archi¬ 
tectures  for  multicast  transport.  Section  5  describes  the  design  of  multicast  routing 
control  protocols  for  use  in  these  architectures.  Section  6  describes  a  case  study  of 
architecture  implementation  over  the  ATM-based  testbed  to  support  multicast-based 
applications  (such  as  multimedia  conferencing).  Section  7  describes  the  strategies 
for  implementing  multicast  on  various  backbone  networks.  Section  8  describes  the 
multicast  support  mechanisms  we  developed  for  end-system  stations.  Sections  9-10 
highlight  the  ‘technical  deliverables’  of  this  project  and  its  relevance  to  Air  Force  Re¬ 
search  Missions.  Sections  11-12  conclude  the  report  by  identifying  the  future  works 
and  research  activities  spawned  off  from  this  project. 

2  Proposed  architectural  elements  of  transport  net¬ 
works 

Our  basic  premise  is  that  a  multicast  transport  architecture  should  be  network¬ 
centric  in  that  the  user-network  interface  should  allow  casting  the  needs  of  appli¬ 
cations  onto  network  internal  mechanisms.  For  example,  a  path  leading  to  audio- 
only  terminals  may  be  set  up  over  a  100  kb/sec  link,  as  against  a  path  leading  to 
video-t-audio  terminals  set  up  over  a  3  mb/ sec  link.  In  such  an  architecture,  the  user- 
level  flow  specifications  are  transcribed  to  the  network  for  the  latter  to  determine  an 
appropriate  data  distribution  path  that  minimizes  the  deployment  of  communication 
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Figure  3:  Distribution  tree  as  building  block  for  multicast  architectures 
resources,  viz.,  link  bandwidth  and  router  node  buffers. 

In  this  section,  we  describe  the  basic  elements  of  multicast  architectures  for  support¬ 
ing  the  QOS  specifications. 

2.1  Distribution  tree 

A  multicast  tree  represents  a  logical  topology  superimposed  on  backbone  network 
nodes  and  links  such  that  a  data  can  be  injected  at  root  node  of  the  tree  and  get 
replicated  along  intermediate  branches  of  the  tree  for  reaching  destinations  at  leaf 
nodes  of  the  tree  [3,  4].  See  Figme  3.  Since  a  tree  topology  does  not  have  cycles,  the 
forwarding  of  a  data  unit  received  over  the  input  link  of  a  node  is  only  a  matter  of 
determining  the  output  links  to  send  the  data  unit.  The  data  from  various  sources 
are  made  available  at  the  root  node  of  a  tree  through  one  or  more  point-to-point 
paths  for  forwarding  towards  destinations. 

Each  node  in  a  multicast  path  implements:  i)  a  routing  function  that  determines 
the  outgoing  links  for  an  incoming  data,  and  ii)  a  resource  allocation  function  that 
reserves  node  buffers  and  link  bandwidths  to  sustain  the  required  data  flow.  The 
setting  up  of  tree-structured  path  and  point-to-point  paths  spanning  the  sources  and 
destinations  in  an  application  is  carried  out  by  a  multicast  routing  algorithm.  The 
path  determination  may  be  based  on  the  total  anaount  of  resource  consumptions  and 
routing  overhead  in  getting  the  data  flows  from  sources  to  destinations  through  the 
backbone  network  (which  constitutes  the  transport  cost). 
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2.2  Paradigms  for  integration  of  QOS  support  in  transport  net¬ 
works 

In  determining  an  appropriate  architecture,  we  employ  ‘programmable  network’  as 
the  imderlying  theme  that  is  becoming  the  basis  for  building  large  networked  systems, 
such  as  the  Internet.  There  are  somewhat  different  schools  of  thought  on  the  notion 
of  ‘programmable  network’: 

Service-oriented  view  [5] :  A  network  model  that  can  offer  a  variety  of  service  classes 
for  data  delivery  such  as  delay  jitter-free  and  jitter-allowed  data  transport 
for  high-fidelity  audio  and  text  based  conferencing  respectively; 

Resource  allocation- oriented  view  [6]:  A  network  model  that  allows  users  to  define 
‘data  flows’  and  their  requirements  which  can  be  passed  on  to  network 
subsystems  for  resource  allocations,  viz.,  bandwidth,  buffers  and  state  in 
the  router  nodes; 

Network-independent  bearer  service  view  [7]:  An  abstract  organization  of  protocols 
and  service  interfaces  not  tied  to  any  existing  protocol  suite,  that  is  ca¬ 
pable  of  cross-connecting  applications  to  backbone  networks. 

We  believe  that  the  above  views  are  intricately  inter-woven  with  one  another,  and 
hence  need  to  be  taken  into  accoimt  in  the  design  of  any  large  network  system. 
Accordingly,  our  formulation  of  tree-based  multicast  transport  architectures  is  guided 
by  these  views. 

A  concretization  of  the  ‘programmable  network’  view  in  transport  architectures  man¬ 
ifests  in  the  following  aspects: 

•  Fine  granular  control  on  network  resource  allocations  through  application  level 
QOS /flow  specifications; 

•  Extensibility  of  allowing  QOS/flow  based  ‘network  parameterization’  for  di¬ 
verse  applications. 

Incorporating  these  aspects,  we  formulated  canonical  models/architectures  for  mul¬ 
ticasting,  and  then  mapped  them  to  operational  backbone  networks  (such  as  ATM 
networks).  Refer  to  Figure  2. 

2.3  Layers  of  transport  functions 

The  source  and  destination  entities  involved  in  a  multicast  data  transport  may  be 
viewed  as  organized  in  a  flat  group  (UTL).  These  entities  exercise  multicast  control 
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Figure  4:  Layers  of  functions  in  a  multicast  transport  architecture 


functions  (MCL)  to  set  up  a  tree-structured  distribution  path  over  the  physical 
topology  of  backbone  network  nodes  and  links  that  can  carry  the  required  data  flows 
from  sources  to  destinations.  The  backbone  network  (BNL)  is  assumed  to  provide 
node-to-node  link  bandwidth  reservation  upon  demand. 

The  UTL,  MCL  and  BNL  functions  are  mappable  onto  appropriate  layers  in  a  target 
network  architecture.  The  mapping  may  involve  the  canonical  functions  in  these 
layers  to  be  boimd  to  the  local  fimctions  in  the  target  network.  See  Figure  4.1n 
interconnected  LANs  for  instance,  the  UTL  functions  reside  in  LAN  applications, 
MCL  functions  in  interconnection  routers,  and  BNL  functions  in  LAN  link-to-link 
connectivity  layer  augmented  with  bandwidth  allocation  control.  In  ATM  networks 
for  instance,  the  BNL  functions  map  to  the  ‘virtual  path’  (VP)  layer  with  ‘native’ 
bandwidth  allocation  support,  and  the  MCL  functions  are  placed  in  the  ‘virtual 
circuit’  (VC)  layer  and  partly  in  the  convergence  layer  above,  exercising  the  VP 
level  multicast  provided  in  ATM  networks  (see  section  6).  Appropriate  convergence 
sublayers  may  be  employed  in  target  networks  to  support  these  mappings. 

Employing  the  tree-structnred  channels  and  the  flow  &  QOS  support  paradigms  as 
building  blocks  of  multicast  transport  architectures,  we  now  describe  the  various 
activities  carried  out  in  the  project. 


7 


3  Shared  tree  based  multicast  architectures 

In  this  section,  we  describe  the  architectural  support  mechanisms  for  multi-source 
data  flows  in  an  application.  These  mechanisms  are  useful  for  mtdtipoint-to-miiltipoint 
communications  where  each  user  entity  in  an  application  can  be  a  source  of  data  as 
well  as  a  destination  for  the  data  from  other  sources.  A  major  application  is  multi- 
media  conferencing. 

3.1  Sharing  of  path  segments 

The  data  stream  from  each  source  flows  over  a  tree  towards  a  common  set  of  desti¬ 
nations.  The  sharing  of  a  tree  segment,  i.e.,  backbone  network  ‘coimection’,  across 
different  data  streams  (‘stream  mtdtiplexing’  over  a  path  segment)  allows: 

•  Amorti2ation  of  the  ‘connection’  fixed  costs  (e.g.,  routing  table  entries  and 
‘connection’  descriptors)  across  the  various  streams; 

•  Better  use  of  ‘connection’  bandwidth  by  exercising  ‘statistical  interleaving’  of 
streams  along  this  segment  and  its  downstream  path  segments,  particularly 
when  data  flows  are  biusty  (such  as  compressed  video  and  text); 

in  comparison  to  sending  each  stream  over  a  separate  ‘coimection’  set  up  over  back¬ 
bone  network  link.  See  Figure  5  that  shows  flows  1  and  2  in  an  application  with 
rates  and  92  respectively.  Empirically,  the  cost  of  these  flows  when  multiplexed 
over  a  single  ‘connection’  set  up  over  a  link  may  be  given  by: 

^mux  =  /c  +  ^•(91  +  92)  when  gi ,  92  are  average  rates 

=  /c  +  ^•(91  +  92)*  when  91,92  are  peedc  rates  (for  bursty  flows),  (1) 

where  fc  is  the  fixed  cost  of  using  the  ‘connection’,  0  <  ife  <  1.0  such  that  data 
loss  does  not  exceed  an  application-specified  limit  A,  and  h  is  a  constant.  The 
equation  (1)  can  be  generalized  to  any  number  of  flows.  Here,  for  a  given  A,  k 
decreases  as  the  number  of  streams  multiplexed,  data  burstiness  and  flow  rate  are 
increased.  And  for  a  given  set  of  flow  parameters,  k  decreases  as  A  is  increased.  Our 
experiments  on  ATM  network  traffic  using  3  bursty  streams  of  15  mbps  each  with 
burst  factor’  of  0.5  show  that  k  =  [0.9, 1.0]  for  A  =  2%  (e.g.,  voice  data  can  tolerate 
up  to  2%  loss  without  noticeable  degradation  in  quality).  When  the  network  cannot 
relate  the  flows  as  belonging  to  a  single  application,  they  may  be  sent  over  separate 
‘connections’  set  up  over  the  link.  Here,  the  cost  of  flows  1  and  2  may  be  given  by 

Cno-mnx  —  2.  fc  +  ^-(91  +  92)  when  9i,92  are  average  rates 
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---->  Stream  2  (rate =q2) 

Figure  5;  Sharing  of  multicast  path  segments  across  streams 

-2.fc  +  h.(9i  +  92)*’’  when  91,92  are  peak  rates  (for  bursty  flows)(2) 

where  k  <  k'  <  1.0.  The  parameter  k'  takes  into  account  any  ‘statistical  interleaving’ 
of  data  units  over  the  link,  as  supported  internally  by  the  backbone  network  (e.g., 
the  multiplexing  of  ‘cells’  of  different  ‘virtual  circuits’  over  ‘virtual  path’  links  in 
ATM  networks,  based  on  network-assigned  ‘bandwidth  classes’). 

As  can  be  seen,  Cnojmux  >  Cmux-  The  less  savings  in  bandwidth  allocation  arise 
because  the  network  does  not  have  information  that  will  enable  it  to  determine  the 
criteria  for  ‘statistical  interleaving’  of  streams  with  respect  to  A.  Thus,  sharing  of 
path  segments  across  data  streams  reduces  the  per-stream  fixed  costs,  and  offers  the 
potential  for  reducing  the  flow  costs. 

The  capability  to  share  tree  channels  across  data  streams  is  itself  specific  to  a  network 
architecture  for  multicasting. 

3.2  Architectural  support  for  shared  trees 

Here,  ‘sharing’  means  that  when  a  stream  gets  combined  with  another  stream,  both 
the  streams  are  routed  through  common  links  all  the  way  downstream  towards  des¬ 
tinations. 

A  key  feature  of  multicast  architectures  is  the  set  of  nodes  in  physical  topology  of 
backbone  network  that  are  allowed  to  be  chosen  as  stream  multiplexing  points  (SMP). 
The  data  from  various  sources  flow  to  a  SMP  node,  and  then  the  combined  data  flows 
along  a  tree  rooted  at  this  SMP  node  towards  destinations.  See  Figure  6.  A  routing 
algorithm  determines  the  data  flow  paths  so  as  to  optimize  the  network-wide  cost 
of  data  transport.  Thus,  for  a  source  in  node  s  and  destinations  in  nodes  {d},  the 
transport  cost  may  be  given  as: 

netjcost{s,  {d})  =  flowjcost{s,  [s,  SMP(s)])  +  mux.flowj:ost{s,  [tT-(SMP(s),  {d})])  + 


Without  sharing 
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Figure  6;  Illustration  of  eirchitectural  support  for  path  sharing 

fixedjcost{[s,  SMP(s)])  +  /ia!erf^o5t([t7‘(SMP(s),  {d})]),  (3) 

where  [s,  SMP(s)]  refers  to  a  point-to-point  path  from  s  to  SMP(s),  and  [tr(SMP(s),  {d})] 
refers  to  the  tree  with  root  at  SMP(s)  and  leaves  at  {d}.  Both  mux.flowjcoat  and 
flow^ost  depend  on  the  number  of  hops  in  a  path  and  the  bandwidth  needs  of  flow 
from  sj  the  trux  -  flow  j^ost  also  depends  on  the  number  of  streams  multiplexed  with 
s  and  the  burstiness  of  various  streams;  the  fixedjcoat  depends  on  the  number  of 
hops  in  a  path,  /c,  and  the  number  of  streams  multiplexed.  In  general,  more  the 
number  of  streams  multiplexed  along  a  path,  lower  the  netjcoat. 

We  now  analyze  the  extent  of  support  for  shared  distribution  paths  in  current  mul¬ 
ticast  architectures. 

3.3  Comparative  analysis  of  multicast  architectures 

Let  V  be  the  set  of  nodes  in  physical  topology  of  the  backbone  network,  and 
{«i}t=i,2,...,JV)  {dj}j=i,2,...,M  C  F  be  the  nodes  containing  source  and  destination 
entities  respectively.  For  a  given  placement  of  {sj}  and  {dj}  in  the  topology,  we 
examine  the  cost  of  multicast  paths  in  various  architectures. 

‘source-rooted  tree’  (SSRT)  architecture 

The  stream  from  each  source  flows  over  a  separate  tree  that  serves  aU  destinations. 
There  is  no  sharing  of  the  common  links  across  various  streams.  So  the  transport 
cost  is  given  by 

net.coat{{ai},  {dy})  =  Y^fixedjcoat{[tr{ai,{dj})])  +  fl<ywjcoat{ai,  Mai,  {dj})]). 

Vi 

The  Internet  Stream  Protocol’  (ST-II)  developed  at  BBN  [8]  and  the  ‘distance  vector 
multicast  routing  protocol’  [9]  fall  under  this  architecture. 
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‘core-based  tree’  (CBT)  architecture  [10] 

The  streams  from  aJl  sources  are  first  collected  at  a  fixed  central  node,  called  the 
‘core’;  the  combined  streams  are  then  sent  over  a  distribution  tree  rooted  at  the  ‘core’ 
and  serving  all  destinations.  Here,  any  node  in  the  tree  that  is  directly  reachable 
from  a  somce  can  serve  as  its  SMP.  The  path  segments  from  the  ‘core’  to  destinations 
are  shared  across  streams,  but  the  point-to-point  paths  from  sources  to  the  ‘core’ 
are  not.  Accordingly,  the  transport  cost  is  given  by 

net_cost({si},  {dj})  =  '^{flowjcost{si,  [s^,  core])  +  fixedj:ost{[si,  core]))  + 

Vi 

fixed jcost{[tr{coTe,  {dj})])  -|-  Y^mux.flowjcost{si,  [tr(core,  {dj})]). 

Vi 


‘rendezvous-point  rooted  tree’  (PIM)  architecture  11] 

The  streams  from  aU  sources  are  first  collected  at  a  fixed  set  of  nodes,  called  the 
‘rendezvous  points’  (RP);  the  combined  streams  are  then  sent  over  the  distribution 
trees  rooted  at  these  RPs  and  serving  each  a  disjoint  subset  of  destinations.  A  source 
connects  to  each  of  the  RP  nodes  separately,  to  serve  as  its  SMP  for  destinations 
connected  by  the  tree  therein.  The  path  segments  from  a  RP  to  its  subset  of  desti¬ 
nations  are  shared  across  streams,  but  the  point-to-pomt  paths  from  sources  to  the 
RP  are  not.  Accordingly,  the  transport  cost  is  given  by 

netjcost{{si},  {dj})  =  {Y^{flowjcost{si,  [si,  z])  -f  fixed^ost{[si,  z]))  -f 

VxeRP  Vi 

fixedjcost{[tr{x,  {dj(z)})])  -f-  '^mux.flowj:ost{si,  [tr{x,  {dj(z)})])  ), 

Vi 

where  dj(z)  is  a  destination  served  by  the  tree  rooted  at  RP  z. 

‘unrooted  tree’  (URT)  architecture  [12,  13,  14] 

The  streams  from  sources  may  be  collected  at  any  set  of  nodes;  the  combined  streams 
are  then  sent  over  the  distribution  trees  rooted  at  these  nodes  and  serving  various 
destinations.  Here,  any  node  in  the  channel  that  is  directly  reachable  from  a  source 
can  serve  as  its  SMP.  In  contrast  to  CBT  and  PIM  architectures,  the  point-to-point 
path  segments  connecting  a  source  to  its  SMP  node  are  sh^lrable  with  other  sources^. 

Accordingly,  the  transport  cost  is  given  by 

netjcost{{si},  {dj})  =  fixedj:ost{[g])  + 

'^{flowj:ost{si,  [si,  SMP(si)])  -1-  mux.flowjcost{si,  [tT-(SMP(si),  {dj})])) 

Vi 

‘The  SMP  function  in  a  node  x  for  a  source  s  can  dynamically  shift  to  an  upstream  node  y  in 
the  point-to-point  path  towards  s  where  a  new  source  s'  connects  to.  Upon  this,  y  becomes  the 
SMP  for  both  s  and  s',  and  the  point-to-point  path  from  y  to  x  gets  shared  by  s  and  s'. 


11 


where  0  is  an  acyclic  graph  such  that  tr{si,  {dj})  C  g\^i  and  Q  =  ljtr(si,  {dj}). 

Vi 

Figure  T  illustrates  the  multicast  paths  for  a  sample  source“destination  configuration 
under  the  SSRT,  CBT,  PIM  and  URT  airchitectures  each. 

3.4  Empirical  studies  on  path  costs 

We  have  studied  a  variety  of  source-destination  configurations  in  physical  topologies 
to  determine  the  network-wide  cost  savings  due  to  the  sharing  of  path  segments  across 
various  data  streams.  With  ‘statistical  multiplexing’  of  bursty  streams,  bandwidth 
savings  of  18-22%  are  possible  across  5  streams  with  a  burst  factor  of  0.25  each  and 
A  =  2%,  for  a  configuration  consisting  of  8  destinations  on  a  25-node  topology.  The 
savings  are  higher  at  about  32%  with  a  burst  factor  of  0.5  and  A  =  5%.  The  savings 
in  fixed  cost  can  be  as  high  as  60%  in  large  sized  configurations  (say,  5  sources  and 
15  destinations  on  a  50-node  topology);  this  savings,  however,  may  be  perceivable 
only  when  the  flow  costs  are  relatively  small. 

Since  the  degree  of  path  sharing  is  influenced  by  the  control  architecture  employed, 
a  cost  comparison  of  multicast  transport  under  different  architectures  can  reveal  the 
extent  of  savings  in  resources  possible  with  respect  to  the  base  case  where  no  sharing 
is  allowed,  as  in  SSRT  (here,  the  fixed  cost  overhead  is  0{N)).  In  many  cases,  the 
degree  of  sharing  emd  the  total  number  of  hops  in  a  multicast  path  counter-balance 
each  other.  For  instance,  an  attempt  to  achieve  the  highest  degree  of  sharing  often 
leads  the  streams  to  a  single  SMP  at  the  ‘geographic  center’  of  the  configuration  for 
onward  flow,  which,  however,  may  increase  the  number  of  hops  the  streams  need  to 
traverse.  Here,  the  savings  in  per-hop  bandwidth  and/or  fixed  overheads  accrued 
from  the  increased  sharing  of  path  segments  can  be  out-weighed  by  the  increased 
‘path  distance’. 

3.5  Implications  on  routing  algorithms 

With  the  incorporation  of  QOS-based  flow  management  into  routing  algorithms,  a 
path  with  the  minimum  number  of  hops  for  a  given  flow  L  —  designated  as  the 
‘shortest  path’  in  current  multicast  routers  —  may  not  always  be  the  path  of  choice 
for  L,  due  to  the  foUowing  reasons: 

•  One  or  more  hops  in  the  path  not  having  adequate  resources  and/or  not  guar¬ 
anteeing  the  delay  constraints  for  L; 
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Figure  7:  Sample  multicast  channel  configurations  in  SSRT,  CBT,  PIM  and  URT 
architectures 


•  A  longer  path  may  offer  a  higher  degree  of  ‘path  sharing’  with  other  flows, 
resulting  in  cost  savings  that  may  more  them  offset  the  cost  of  sending  L  over 
additional  hops^. 

Thus  determining  a  cost-optimal  multicast  path  is  a  computationally  complex  task. 

The  sharing  of  distribution  paths  across  multiple  streams  casts  itself  upon  routing 
algorithms  in  the  form  of:  i)  constraints  on  the  choice  of  nodes  in  a  distribution  path, 
ii)  the  extent  of  routing  control  actions  required  during  path  setup,  and  iii)  adaptivity 
to  dynamic  changes  in  source-destination  configuration  and  flow  parameters.  The 
actual  resource  consumptions  and  cost  incurred  for  multicast  paths  depend  on  the 
flow  specifications  and  the  source-destination  configuration  in  physical  topology. 

In  SSRT  model,  each  source-rooted  tree  can  be  individually  minimized,  but  these 
non-sharable  trees  together  do  not  always  yield  minimality  for  the  entire  source- 
destination  configuration.  In  CBT  model,  cost  mimmization  of  the  ‘core-rooted’ 
tree  and  the  non-sharable  point-to-point  paths  from  various  sources  to  ‘core’  node 
together  need  not  be  the  best.  This  is  because  of  the  need  to  send  all  data  to  the 
‘core’,  which  limits  the  ‘spread-out’  of  channel  topology  towards  paths  of  lower  cost. 
In  Figure  7  for  instance,  an  optimal  placement  of  ‘core’  node  in  X  for  the  sources 
si,  S2  and  destinations  d*,  dy,  d*  may  not  yield  cost  minimality  any  more  when,  say, 
one  of  the  destinations  leaves  or  a  new  source/ destination  joins  the  configuration. 
A  similar  argument  holds  for  PIM  model  with  respect  to  ‘rendezvous-point’  nodes. 
With  URT  model,  the  trees  projected  at  various  sources  can  be  analyzed  together  for 
shared  path  segments,  £ind  can  be  ‘spread  out’  with  less  constraints  towards  lower 
cost  paths.  Thus  the  cost  minimality  achievable  in  vauious  models  can  be  different. 

See  [14,  15]  for  detailed  comparison  of  various  architectures  from  transport  cost  and 
routing  algorithm  perspectives. 

Our  treatise  on  network  support  for  shared  distribution  paths  allows  one  to  determine 
how  far  the  application-level  flow/QOS  specifications  can  be  taken  down  into  the 

^  An  example  of  analogy  is  the  ‘ride-shaie’  used  by  commuters  traveling  to  workplaces  in  big  cities 
(such  as  Los  Angeles  and  New  York  City).  Consider  2  commuters  x  and  y  traveling  to  a  workplace 
z.  They  may  ride  in  separate  cars  to  a  ‘park-and-ride’  lot  r  and  travel  therefrom  in  a  single  car  to 
z.  In  many  cases,  this  may  be  more  cost-effective  than  z  and  y  riding  in  separate  cars  each  all  the 
way  up  to  z.  This  may  be  the  case  even  if  the  total  distance  traveled  to  r  and  then  on  to  z  is  higher 
for  z  and/or  y  individually.  Here,  the  notion  of  cost-effectiveness  is  based  on: 

—  The  eimortization  of  fixed  costs  in  using  a  car,  viz.,  the  ‘mechaiucal  wear-and-tear’,  ‘driver 
fatigue’  and  ‘highway  tolls’,  across  riders  z  and  y; 

—  Less  amount  of  variable  costs,  viz.,  ‘gasoline  consumption’,  by  a  single  car  with  the  2  riders  z 
and  y,  in  comparison  to  that  by  separate  cars  for  z  and  y  each  combined. 

The  use  of  ‘ride-share’  is  subject  to  the  constraint  that  any  increased  travel  time  of  z  and  y  is  less 
than  their  ‘tolerable  commuting  delay’. 
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Figure  8:  Illustration  of  fiow-to-resource  mapping  tables  in  nodes 


network  to  influence  its  behavior  (i.e.,  ‘network  programmability’)  and  the  tradeoffs 
involved  therein. 


4  Network  elements  for  resource  control 

In  a  canonical  form,  multicast  support  in  the  network  requires  flow/QOS  based 
functional  elements  that  can  be  appropriately  exercised  for  resource  allocation  and 
routing  control  purposes. 

4.1  Switch  level  resource  allocator 

A  switch  5  may  employ  a  functional  relation  T  that  maps  a  flow  rate  to  resources, 
viz.,  link  bandwidth  needed  to  support  the  flow  rate  and  switch  buffers  needed  for 
sending  and/or  receiving  data  through  a  port  at  this  rate.  5  may  realize  T  in  the 
form  of  pre-computed  tables  that  relate  the  niunber  of  streams  multiplexed,  their 
average  flow  rates  and  burstiness,  and  the  application-wide  parameter  A  to  the 
bandwidth/buffer  needs.  See  Figure  8  for  an  illustration. 

A  specific  implementation  of  these  resources,  such  as  the  processing  cycles  consumed 
in  5  to  support  a  flow,  is  itself  a  switch  internal  issue  that  does  not  concern  a  routing 
control  protocol.  However,  the  quantification  of  resource  needs  for  a  given  flow  has 
a  global  scope  so  that  the  network-wide  cost  of  a  path  through  S  can  be  estimated. 
In  other  words,  5  should  support  a  quantifiable  abstraction  of  resources  in  order  to 
interwork  with  a  routing  algorithm.  The  de-lineation  of  estimating  the  resomce  needs 
for  a  flow  and  a  local  implementation  of  resources  in  switches  should  be  guaranteed 
by  the  BNL. 
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For  this  purpose,  a  backbone  network  may  implement  a  convergence  sublayer  to 
export  a  global  view  of  resources,  hiding  their  local  implementation.  The  global 
view  is  then  integratable  into  a  MCL  function. 

4.2  Switch  level  QOS  controller 

With  a  ‘multicast  tree’  sharable  by  more  than  one  data  stream,  the  ability  to  dis¬ 
tinguish  the  various  data  streams  may  still  be  needed  in  the  network  to  handle  the 
QOS  related  transport  attributes  (say,  to  map  the  ‘loss  sensitivity’  and  ‘acceptable 
delay  jitter’  of  various  data  to  scheduling  priorities  on  data).  For  this  purpose,  the 
various  flow  related  parameters  specified  by  users  are  keyed  on  stream  ids. 

An  important  QOS  parameter  is  the  acceptable  end-to-end  delay  of  data  units,  i.e., 
the  maximum  allowable  delay  between  when  a  data  unit  is  generated  by  a  source 
and  when  it  is  consumed  by  a  destination.  Since  each  hop  in  a  path  segment  can 
add  a  certjiin  amoimt  of  data  transfer  delay,  the  end-to-end  delay  constraint  may 
influence  the  setting  up  of  tree  connecting  various  destinations.  It  is  also  likely  that 
destinations  will  be  able  to  determine  the  level  of  acceptable  end-to-end  delay  on 
a  data  stream.  In  a  multimedia  conferencing  application  involving  audio  and  video 
streams  for  example,  an  interactive  participant  may  specify  50  msec  as  the  end-to- 
end  delay,  while  a  passive  participant  may  specify  250  msec.  This  receiver- specific 
delay  control  allows  more  flexibility  in  path  selections  by  a  routing  algorithm. 

Each  node  u  of  a  tree  medntains  information  on  the  cumulative  delays  incurred 
by  the  various  streams  {a}  flowing  through  u,  denoted  as  {strjdel{s,  u)}.  For  this 
pTirpose,  u  may  obtain  the  hop  delay  information  (from  BNL)  for  its  incoming  path 
segments  from  various  upstream  neighbors  (there  can  be  more  than  one  upstream 
neighbor  in  URT  and  CBT  architectures,  and  exactly  one  upstream  neighbor  in 
PIM  architecture).  A  cemdidate  path  that  connects  a  destination  d  to  a  source  s 
through  node  u  in  the  tree  should  have  the  sum  of  delays  from  a  to  u  and  from  u 
to  d  less  than  the  prescribed  end-to-end  delay  limit  delg{s,d).  See  Figure  9  for  an 
illustration.  From  among  such  candidate  paths,  the  routing  algorithms  chooses  a 
path  that  minimizes  netjcost{s,  {d}). 

4.3  Stream  filters 

A  source-selective  receipt  of  data  by  destinations  (e.g.,  an  audio-only-capable  ter¬ 
minal  participating  in  a  video-faudio  conference  session)  may  be  supported  in  the 
network  by  filtering  of  data  streams  at  various  nodes  of  a  shared  tree.  The  filter 
prevents  a  stream  from  flowing  along  path  segments  that  lead  only  to  destinations 
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Delay  table  in  node  i 


Figure  9:  Illustration  of  end-to-end  delay  control  information  in  switches 

not  requiring  this  stream,  thereby  saving  resources  along  these  path  segments.  This 
functional  element  is  somewhat  similar  to  the  ‘upward  pruning  of  distribution  trees’ 
proposed  in  RSVP  [16]. 

A  destination  d  which  does  not  wish  to  receive  data  from  si, S2> •  • ' > in¬ 
cludes  the  list  of  stream  (id, rate)  pairs  {(•Si>9j)}j=i,2 . m>  referred  to  as  ‘source 

mask’  src^sk{d),  as  part  of  the  flow  attributes  it  specifies,  where  N  is  the  number 
of  sources  in  the  application.  The  network  splits  the  combined  data  stream  flow¬ 
ing  through  the  tree  at  an  appropriate  node  u  to  isolate  a  stream  not  specified  in 
srcjmsk,  for  downward  flow  from  u  towards  d.  This  is  done  with  a  filter  installed 
adong  a  path  e  of  «  through  which  d  is  reachable.  The  filter  maintains  a  mask  list 
kJst{u,e)  =  {(sj,9j)},  and  forwards  only  the  data  units  carrying  a  stream  id  not 
listed  in  kJst{u^  e)  through  e.  Note  that  when  no  filtering  is  required,  kJst{u,  e)  =  0. 

Given  that  d  does  not  wish  to  receive  data  from  a  source  Si,  the  network  may  install  a 
filter  at  each  node  in  the  upstreaun  path  segment  up  to  the  node  that  roots  a  subtree 
with  more  than  one  branch  amd  the  data  is  needed  along  at  least  one  of  these  other 
bramches.  The  filter  instadlation  also  involves  de-aUocating  resources  to  the  extent  of 
T{qi)  at  each  node  in  this  upstream  path  segment.  Thus  the  flow  from  Si  is  ON  if  at 
least  one  destination  wishes  to  receive  from  Si.  When  none  of  the  destinations  wish 
to  receive  from  Si,  the  filter  mechainism  automaticaiUy  turns  OFF  Si.  See  Figure  10 
for  illustration. 

The  network  functional  elements  described  in  this  section  axe  exercisable  by  user 
level  primitives,  invoked  through  a  multicast  service  interface  (MSI).  See  Figure 
11.  The  interactions  between  the  functionad  elements  may  be  modeled  using  am 
‘object-oriented’  pairadigm,  which  allows  these  elements  to  be  easily  incorporated 
into  ‘resoTirce  signaling’  systems. 
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Figure  10:  Illustration  of  network  supported  filters  of  data  streams 
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Figure  11:  A  ‘signaling’-oriented  structure  of  multicast  service  interface 


We  now  describe  routing  control  protocols  that  allow  exercising  the  network  func¬ 
tional  elements  when  user  entities  connect /disconnect  to/from  a  multicast  channel. 


5  Design  of  multicast  routing  control  protocols 

The  protocol  support  for  multicast  consists  of:  i)  decentralized  information  struc¬ 
tures  maintained  at  various  nodes  to  support  network  functional  elements,  and  ii) 
control  message  space  required  to  exchange  these  information  across  nodes.  We  first 
present  a  high  level  view  of  routing  algorithms  in  terms  of  this  protocol  support. 

5»1  Functionsl  dBcomposition  of  routing  algorithms 

A  multicast  routing  algorithm  may  be  viewed  as  consisting  of  the  following  compo¬ 
nents  (see  Figure  12): 
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Figiare  12:  Functional  components  of  multicast  routing  algorithms 

•  Mapping  of  user-level  flow  specifications  %  to  resource  demands  at  a  node/link; 

•  Determining  the  network-wide  resource  needs  of  various  interconnection  paths 
for  a  given  source-destination  configuration  C; 

•  Optimizing  a  cost  index  #  in  selecting  the  data  paths; 

•  Enforcing  the  architectural  constraints  A  on  path  selection. 

Thus  a  routing  algorithm  is  representable  as 

A  routing  algorithm  obtains  global  knowledge  of:  i)  data  flows  network-wide  from 
various  sources  to  destinations  (i.e.,  Tt)  based  on  user  level  specifications  of  data 
directionality,  data  rates  and  source-selectivity,  and  ii)  the  configuration  information 
(i.e.,  C)  based  on  relative  placement  of  source  and  destination  entities  in  physical 
topology  of  backbone  network.  With  the  above  information,  the  costs  of  various 
possible  data  paths  between  sources  and  destinations  imder  the  chosen  architecture 
(i.e..  A)  may  be  computed  so  that  a  path  meeting  a  cost  and  delay  constraint  (i.e., 
#)  is  determined.  In  the  presence  of  dynamic  changes  in  the  configuration,  §  may 
refer  to,  for  instance,  a  ‘network-wide  minimal  cost’  path  across  every  change  and  a 
‘incrementally  minimal  cost’  path  at  each  change. 

See  [4,  17,  18]  for  representative  cost-based  routing  methods.  The  notion  of  ‘geo¬ 
graphic  spread’  based  cost  minimization  proposed  in  [19]  seems  to  be  appropriate. 
However,  it  needs  to  be  augmented  with  the  data  flow  characteristics  for  effective 
use  in  multi-service  networks.  Consider,  for  insteince,  2  sources  si  and  S2  ui  ^  config¬ 
uration.  A  case  where  high  bandwidth  video  data  flows  from  Si  and  low  bandwidth 
audio  data  flows  from  S2  is  different  from  a  case  where  only  audio  data  flows  from  Si 
and  S2  each.  In  the  former  case,  the  paths  from  si  and  S2  to  destinations  are  likely 
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to  be  accentuated  more  towards  connecting  si  to  destinations  with  less  number  of 
hops,  while  in  the  latter  case,  these  paths  are  likely  to  be  evenly  spread  out,  in  the 
physical  topology. 

5.2  End-to-end  delay  constraints 

The  architecture  specification  A  may  also  influence  the  setting  up  of  paths  with 
end-to-end  delay  guarantees.  This  is  because  an  architecture  restricts  the  selectable 
set  of  paths  to  only  a  subset  of  paths  feasible  in  the  physical  topology. 

Consider  a  destination  d  joining  a  channel  configuration  connecting  to  sources  si 
and  52-  In  CBT  architecture,  the  delay  condition  is: 

struiel{x,SM.P{x))  -f-  str^e/(SMP(i), d)  <  delq(x,d%=,^^,^, 

where  SMP(ai)  and  SMP(52)  may  be  any  of  the  nodes  in  the  ‘core’-rooted  tree. 
In  PIM  architecture,  the  above  condition  needs  to  be  evaluated  for  placement  of 
SMP(5i)  and  SMP(32)  in  the  RP  node  that  serves  d.  Suppose  the  above  condition 
does  not  hold.  With  CBT  architecture,  d  cannot  connect  to  the  channel.  The  PIM 
architecture  however  allows  d  to  bypass  the  RP  node  and  set  up  a  source-rooted  tree 
to  ai  and  S2  each  that  meets  the  delay  condition  (thus,  the  RP-tree  and  source-rooted 
trees  coexist).  Since  the  URT  architecture  does  not  pre-designate  any  particular  node 
to  serve  as  SMP,  it  is  possible  for  d  to  change  the  choice  of  SMP  node  for  Si  and  S2 
such  that  the  delay  condition  can  be  met.  This  reduces  the  probability  of  ‘connect’ 
failures. 

In  a  modification  to  the  CBT  architecture  [20],  the  ‘core’  can  be  dynamically  split 
into  many  ‘core’  nodes  if  the  path  to  one  or  more  destinations  from  the  current  ‘core’ 
node  does  not  meet  the  delay  condition.  The  topological  placement  of  such  ‘dynamic 
core’  nodes  needs  to  be  carefully  done  because,  in  some  extreme  cases,  the  join  of 
each  destination  Ccui  cause  a  re-assignment  of  aU  the  ‘core’  nodes. 

We  now  describe  the  protocol  model  that  we  have  designed  in  this  project,  to  allow 
systematic  acquisition  and  use  of  source- destination  configuration  information  by 
a  routing  algorithm.  The  latter  may  use  this  information  to  optimally  exercise 
network-wide  resource  allocation  control. 


5.3  Routing  control  protocol 


The  functional  view  of  routing  algorithms  underscores  a  canonical  protocol  model 
that  defines  the  decentralized  flow-related  information  structures  maintained  by 
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C  ■ ')  Routing  protocol  agent  specifications 

„  ,  .  ij^i,  .  Multicast  channel  through  which 

-  Backbone  network  link  protocol  control  messages  flow 

Figtire  13:  Protocol  model  for  multicast  path  set  up 

‘agents’  executing  at  various  nodes  in  the  connectivity  configuration  C  and  the  rout¬ 
ing  control  messages  exchanged  between  these  ‘agents’  to  access  the  flow  information. 
See  Figure  13. 

The  messages  propagate  user-level  flow  specification  and  source-destination  config¬ 
uration  information  to  the  ‘agents’  in  various  nodes.  The  messages  also  carry  infor¬ 
mation  on  resource  allocations  at  various  nodes/links  and  the  overhead  and  delay 
incurred  on  the  ‘native  connections’  over  these  nodes/links.  Representative  types  of 
messages  include: 

•  ‘search’  messages  to  locate  SMP  nodes  that  can  support  the  required  flow 
from/to  user; 

•  ‘resource  check’  messages  to  ascertain  the  availability  of  resources  and  the  end- 
to-end  delay  guarantees  along  downward  path  segments  to  support  a  flow; 

•  ‘path  setup’  messages  to  iillocate  resources  at  nodes  in  the  path  through  a 
given  node; 

•  ‘stream  tap’  messages  to  locate  a  stream  flowing  along  upward  paths  and  bring 
it  to  a  given  node; 

•  ‘path  tear  down’  messages  to  de-aJlocate  resources  along  chosen  path  segments; 

•  ‘stream  remove’  messages  to  delete  a  stream  flowing  through  a  node  and  along 
its  upward  path  segment  up  to  a  point  where  the  stream  needs  to  flow  along 
other  breinches  of  the  tree. 
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Multicast  control  architectures 
(CBT,  PIM,  URT) 


Figure  14:  A  ‘protocol-oriented’  view  of  resource  control  system 

During  execution,  the  protocol  may  root  a  tree  at  ciny  chosen  node  to  propagate 
these  control  messages  to  all  other  nodes  in  the  path  segments. 

Details  of  the  protocol  model  in  terms  of  canonical  information  structures  main¬ 
tained  at  ‘agent’  nodes  and  the  control  message  flows  across  nodes  to  access  these 
information  may  be  foimd  in  [21].  The  model  is  closely  related  to  the  ‘Resource 
Reservation  Protocol’  (RSVP)  [16]  and  the  ‘Internet  Stream  Protocol’  (ST-II)  [8]  in 
light  of  their  scope  towards  multi-service  applications. 

Our  design  philosophy  has  been  that  the  protocol  structure  is:  i)  canonical  and 
architecture-independent  (e.g.,  ‘stream  filter’  mechanism  should  be  the  same  for  both 
CBT  emd  URT  eirchitectures),  cind  ii)  open-ended  to  allow  architecture-specific 
extensions  (e.g.,  the  use  of  a  ‘miicast  protocol’  to  locate  the  ‘core’  node  in  CBT 
and  a  ‘cache’  of  potential  access  point  node  addresses  in  URT).  See  Figure  14.  The 
various  aspects  of  our  protocol  model  reflect  this  philosophy. 

5.4  Simulation  studies 

The  protocol  model  was  studied  by  extensive  simulations  of  routing  algorithms  that 
set  up  cost  optimal  paths,  under  the  URT  architecture.  Large  sized  topologies  were 
simtdated  (50-100  nodes  with  ‘node  degree’  of  2-5),  with  dynamic  application  con¬ 
figurations.  Two  types  of  metrics  were  analyzed: 

•  The  ‘time  overhead’  and  ‘control  message  overhead’  incurred  network-wide  to 
effect  configuration  changes; 

•  The  ‘degree  of  path  sharing’  across  v^uious  data  flows,  as  achievable  by  the 
protocol. 
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The  ‘time  overhead’  may  indicate  the  latency  experienced  by  joining  user  entities; 
this  may  translate  to,  for  example,  a  ‘TV  chaimel  switching  time’  in  digital  TV 
receivers.  The  ‘message  overhead’  may  indicate  a  one-time  network-incurred  cost  of 
effecting  the  join  of  a  user  to  a  configuration.  The  ‘degree  of  sharing’  may  indicate 
the  network-wide  savings  possible  in  flow-related  resource  allocations  for  a  given 
configuration.  An  analysis  of  these  metrics  for  a  variety  of  network  topologies  and 
application  configurations  indicates  a  feasibility  of  the  protocol  model  for  use  in 
multicast  networks.  See  [21,  22]  for  details  of  these  simulation  studies. 

The  functional  elements  and  message  structures  defined  for  the  protocol  are  common 
across  the  CBT,  PIM  and  URT  architectures.  Architecture-specific  extensions  c£in 
be  incrementally  added  in  the  target  implementation  of  a  routing  algorithm.  These 
details  may  also  be  foimd  in  [21].  In  a  degenerate  form  that  does  not  employ  flow 
aggregation,  the  protocol  can  also  support  the  SSRT  architecture. 


6  Implementation  study  over  ATM  networks 

We  have  studied  the  functional  model  of  multicast  routing  algorithms  on  an  ATM 
network  consisting  of  5  nodes  (Fore  and  GTE  switches)  and  3  SUN-Sparc  worksta¬ 
tions.  These  workstations  implement  the  source  and  destination  entities. 

6.1  Routing  protocol  overlay 

Since  the  native  ATM  switches  do  not  support  our  functional  model,  we  placed  the 
protocol  agents  in  ‘logically  extended  switches’  (LES),  implemented  on  (additional) 
workstations  attached  to  native  ATM  switches.  LES  realizes  the  protocol  overlay, 
with  a  convergence  layer  for  ATM  networks  (see  Figure  15).  The  VP/VC  set  up 
and  VP  level  b£tndwidth  allocation  functions  provided  in  the  native  ATM  switches 
are  available  to  the  agents  in  LES  through  a  programming  interface.  The  physical 
topology  of  backbone  network  is  basically  a  set  of  VP  links  interconnecting  the 
various  switches.  Data  flow  paths  and  control  message  paths  are  realized  through 
sepau'ate  VCs  multiplexed  on  common  VP  links  (a  VP  link  is  a  unidirectional  channel 
between  a  pair  of  ATM  switches). 

Data  paths  generated  by  the  routing  algorithm  are  specified  in  terms  of  bandwidth 
needs  on  each  VP  link  and  the  filters  placed  along  each  VP  link.  The  logical  topology 
of  data  paths  is  then  embedded  onto  the  ATM  network  VC/VPs  as  follows.  The 
estimated  beindwidth  needs  for  a  VP  link  are  transcribed  into  the  native  switch 
bandwidth  allocation  for  VP  links.  A  distinct  VC  is  assigned  to  each  stream  in  the 
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Figure  15:  An  implementation  structure  for  ‘network  level  signaling’  to  support 
resource  allocations  in  ATM  networks 


application  (as  suggested  in  [23]).  Multiple  VCs  share  one  or  more  common  VP 
links,  as  allowed  by  the  multicast  control  architecture®.  A  stream  filter  along  an 
outgoing  VP  link  is  realized  by  simply  not  including  the  corresponding  VCI-VPI 
mapping  entry  in  the  switch  tables  for  this  VP  link.  A  bidirectional  path  segment  is 
realized  with  2  unidirectional  VC/VPs  since  the  native  ATM  switches  support  only 
unidirectional  channels. 

The  ‘statistical  multiplexing’  of  VCs  over  a  VP  based  on  ‘bandwidth  classes’,  as 
allowed  by  ATM  switches,  can  be  exploited  in  a  coarse  maimer  by  mapping  the  flow 
rate  q  into  an  appropriate  ‘bandwidth  class’  and  mapping  the  A  to  one  of  the  allowed 
‘ceU  loss  priority’  values.  Further  studies  are  required  to  establish  a  tighter  linkage 
between  our  resource  model  and  the  ATM  ‘network  service’  offerings. 


6.2  ‘native  ATM  signaling’  support 

Since  the  ‘native  signaling’  protocols  employed  in  FORE  and  GTE  switches  set  up 
only  SSRT  paths  using  SVCs  —  ‘switched  virtual  circuits’,  we  resorted  to  the  use 
of  PVCs  —  ‘permanent  virtual  circuits’  —  to  create  shared  multicast  VP  links. 

’Bandwidth  savings  due  to  link  sharing  across  bursty  flows  could  not  be  determined  from  this 
testbed,  since  the  current  version  of  ATM  switches  aUocate  the  entire  bandwidth  for  streams  in  the 
absence  of  contention  and  we  could  not  generate  enough  traffic  to  saturate  the  switch  capacity  of 
625  m^j.  However,  a  separate  study  using  ATM  ‘ceU  traffic  analyzer’  equipments  confirm  that 
bandwidth  savings  are  possible  due  to  ‘statistical  interleaving’  of  bursty  streams. 
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Here,  bandwidth  estimates  for  aggregated  flows  are  computed  by  LES  nodes,  which 
are  then  used  in  the  setting  up  of  the  required  PVCs.  In  this  context,  it  may  be 
noted  that  works  are  being  pursued  elsewhere  to  support  ‘shared  trees’  over  ATM 
networks  [24].  A  spin-off  of  these  works  is  to  integrate  flow  management  into  ATM 
coimectivity  setup  protocols  and  provide  signaling  support  functions  therein. 

6.3  Application  configurations 

Two  distinct  application  configurations  are  studied:  one  with  4  streams  (2  video  and 
2  audio)  and  4  destinations  spread  out  across  3  workstations  and  the  other  with  4 
streams  (2  text  and  2  graphics)  and  2  destinations  spread  out  across  2  workstations. 
The  routing  algorithm  employs  ‘incremental  path  setup’  as  the  cost  constraint,  eUid 
incorporates  the  architectural  requirements  of  CBT,  PIM  or  URT,  as  the  case  may 
be.  The  algorithm  generates  paths  in  each  of  these  architectures,  specified  in  terms  of 
bandwidth  needs  on  each  VP  link  and  the  filters  placed  cdong  each  VP  link.  Stream 
delay  information  is  also  generated  by  the  algorithm  at  each  LES  in  a  path^.  Our 
experiments  on  the  above  system  environment  indicate  that  the  time  to  complete 
the  ‘join’  activity  of  a  user  is  less  than  20  msec. 

The  total  number  of  distinct  VP  links  required  network-wide  to  support  both  the 
application  configurations  (fixed  cost  overhead)  under  the  URT,  SSRT,  CBT  and 
PIM  architectures  are  foxmd  to  be  20,  36,  28,  and  30  respectively.  This  indicates 
the  extent  of  resource  savings  possible  with  the  URT  architecture  over  other  existing 
architectures. 

As  a  qu£ilitative  note,  our  functional  model  of  routing  algorithms  allowed  an  easier 
realization  of  various  architectures  and  cost  constraints.  In  fact,  that  it  would  have 
been  impossible  to  implement  miilticast  routing  for  multi-service  networks  with  a 
traditional  ‘monolithic’  view  of  routing  algorithms  is  not  an  over-statement. 

7  Study  of  multicasting  over  heterogeneous  networks 

We  employed  the  URT  model  as  a  reference  multicast  architecture  in  this  study.  The 
results  of  the  study  can  however  be  extrapolated  to  the  CBT  and  PIM  architectures 
as  well. 

To  allow  the  mapping  of  MCL  functions  onto  specific  backbone  networks,  we  adopted 
a  network-wide  logical  addressing  of  URT  channels  that  allows  establishing  loc2d 

^Stream  delay  information  is  of  less  consequence  in  this  small  testbed  under  study,  except  for 
validating  the  algorithm  functionality  of  enforcing  delay  control. 
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bindings  between  a  logical  address  and  the  information  on  network- specific  routing 
of  data  over  switches  and  links.  For  instance,  the  ‘communication  division’  of  Rome 
Laboratory  may  subscribe  to  a  logical  address  that  may  be  used  by  the  routing 
system  to  deliver  packets  at  various  workstations  belonging  to  this  division.  The 
logical  addressing  allows  grouping  of  selected  destinations  to  overlay  different  ‘virtual 
networks’  on  a  base  level  multicast  channel  (e.g.,  private  discussion  groups  in  a 
conference).  As  a  demonstration  of  this  architectural  feature,  we  designed  strategies 
for  the  embedding  of  the  URT  model  on  sample  backbone  networks:  interconnected 
LANs  and  ‘SMDS  networks’  (Switched  Multimegabit  Data  Service) 

7.1  Semantics  of  logical  addresses 

A  channel  Q  is  bound  to  a  unique  logical  address  addr  that  may  be  used  as  a 
network-wide  index  for  the  imderlying  multicast  path.  The  addr  may  be  specified 
at  the  time  G  is  created  by  a  user  level  management  entity,  and  may  be  inherited 
by  every  router  node  of  Q.  A  user  entity  U  may  connect  to  Q  by  specifying  addr. 
A  multicast  routing  algorithm  uses  addr  as  a  key  to  locate  a  SMP  in  G  for  creating 
a  path  segment  between  U  and  the  SMP.  A  source  prefixes  each  data  packet  sent 
across  the  UTL-MCL  interface  with  a  label  in  the  header  containing  addr,  to  enable 
the  routing  system  in  the  network  determine  the  path  through  which  the  packet  is 
to  traverse. 

A  logical  address  addr  binds  only  to  a  multicast  path,  but  not  (directly)  to  the 
entities  participating  in  data  exchanges  over  this  path.  This  semantics  allows  route 
processing  based  on  addr  to  be  an  integr^d  part  of  multicast  implementation  on 
backbone  networks.  In  contrast,  existing  group  addressing  schemes  directly  bind  the 
user  level  entities,  as  a  group,  to  a  single  address,  such  as  the  ‘host  group  address’ 
for  inter-machine  communications  over  LANs  and  Internet  [2,  25].  As  a  case  of 
logical  addressing,  the  32-bit  imstructured  format  of  ‘IP  Class-D’  address  [1]  is  a 
siiitable  candidate  for  assignment  to  a  URT  cheinnel,  that  employs  ‘IP  multicast’ 
based  link-to-link  data  connectivity  among  the  component  gateway  nodes.  Figure 
16  illustrates  ‘network-oriented’  and  ‘user-oriented’  addressing  schemes  employed  in 
data  trcinsport  networks. 

The  UTL  entities  at  various  access  nodes  need  to  manage  the  shared  logical  address 
space  {addr}  for  allocation  and  de-allocation  of  addresses  to  multicast  paths  and  bind 
these  addresses  to  application  level  names  of  communicating  objects  implemented 
by  the  UTL  entities.  Such  a  function  may  be  provided  as  part  of  a  systemwide  name 
service.  The  evolving  standards  such  X.121  ‘subscriber  addressing’  [26]  and  SMDS 
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Figure  16:  Path  addressing  in  various  layers  of  multicast  network  architecture 
‘group  addressing’  [27]  may  be  used  to  assign  application  level  names. 

7.2  Packet  forwarding 

Consider  a  set  of  URT  channels  that  each  pass  through  a  switch  5.  Each  of  these 
channels  may  have  path  segments  to  one  or  more  neighbors  of  5.  This  information 
is  maintained  by  5  in  a  routing  table,  with  each  entry  in  the  table  corresponding 
to  a  channel.  For  a  channel  bound  to  address  addr,  the  corresponding  table  entry 
provides  a  mapping  of  the  form 

addr  {pJdi,pJd2, . . .  ,p-idr} 

with  I  <r  <  K,  where  pJdr  is  the  port  through  which  5  has  an  edge  to  a  neighbor 
and  K  is  the  number  of  ports  of  5  in  the  physical  topology.  As  can  be  seen,  5 
does  not  have  complete  information  about  a  route.  Instead,  a  decentralized  structure 
of  the  routing  information  is  employed  namely,  S  only  knows  through  which  of  its 
ports  (or,  links)  the  entities  connected  to  addr  can  be  reached.  This  technique  is 
known  as  late  binding  of  routes. 

With  source-routing,  the  network  level  agent  of  a  source  entity  residing  in  a  switch 
So  maintains  the  routing  information  for  the  entire  tree  rooted  at  5o.  In  general, 
the  subtree  rooted  at  a  switch  5  is  representable  as  an  ordered  list  of  port  ids  in  the 
form 


list{addr)  =  [{pJdi,listi),  [pJ,d2,list2),  ...,  {pJdr,listr)], 

where  listj  represents  a  subtree  rooted  at  switch  5^  to  which  5  has  a  branch  through 
pJdj(_i^2,...,r)-  To  multicast  a  packet,  S  sends  the  packet  through  each  pJdj  affixing 
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listj  in  the  packet  header.  On  receiving  the  packet,  uses  listj  as  the  tree  to  multi¬ 
cast  the  packet  through.  This  type  of  routing  may  reduce  the  per-packet  processing 
overhead  by  avoiding  the  routing  table  lookup. 

The  source-routing  may  be  useful  for  ‘closed  user  group’  connections  (e.g.,  small  con¬ 
ference  sessions,  replicated  database  access)  and  unicast  channels  where  the  number 
of  leaves  in  a  tree  is  not  large,  say  <  10,  and  hence  the  header  overhead  to  carry  the 
port  list  can  be  a  small  fraction  of  the  channel  bandwidth.  For  example,  a  4-bit  field 
for  pJdj.  [K  <  16),  a  4-bit  delimiter  field  for  various  branches  at  a  node,  ^  =  0.1 
and  up  to  4  hops  along  the  tree  can  require  a  header  approximately  of  size  20  bytes 
to  Ccirry  the  list  of  ports.  This  consumes  about  4%  of  the  bandwidth  allocated  for 
a  path,  assuming  512-byte  packets.  This  overhead  when  compared  to  that  caused 
by  a  4-byte  field  to  carry  an  addr  in  the  header  may  be  acceptable  in  light  of  the 
packet  processing  overhead  saved  on  a  routing  table  lookup  for  every  data  packet. 
With  ‘open  user  group’  connections  (e.g.,  large  conference  sessions,  broadcast  TV 
and  audio)  however,  the  number  of  leaves  may  be  large,  say  100.  So®  the  header 
size  can  be  as  high  as  100  bytes  using  the  earlier  example  with  ^  =  0.5,  which 
consumes  about  20%  of  the  bandwidth.  Such  an  overhead  may  not  be  acceptable 
when  the  scalability  of  implementation  with  the  size  of  application  configurations  is 
important. 

Thus  the  advantage  of  source-routing  over  late  binding  of  routes  in  the  form  of 
increased  packet  switching  efficiency  is  limited  to  only  when  the  branching  factor 
of  the  tree,  indicated  by  is  small  (as  in  connections  with  unicast  entities  cind 
some  ‘closed  user  groups’)  because  of  the  size  of  the  list  carried  in  the  packet.  So 
source-routing  may  be  resorted  to  only  as  an  alternative  to  late  binding  of  routes, 
rather  than  as  a  rule. 

Overall,  the  network  support  for  both  routing  modes  as  part  of  logical  addressing  is 
desirable  for  multi-service  networks. 

7.3  Implementation  strategies  for  IP  LANs 

Consider  a  URT  channel  that  spans  across  a  LAN  X  and  an  IP-based  internetwork 
of  LANs  y.  The  MCL  in  the  gateway  G  that  interconnects  X  and  Y  is  basically  a 
guest  level  implementation  in  which  the  ‘logical  link  control’  (LLC)  layer  of  X  emd 
the  IP  layer  of  Y  are  viewed  as  providing  subnet- specific  multicast  facilities  across 
the  ‘LAN  hosts’  residing  in  X  and  Y  respectively.  So  the  MCL  maps  the  logical 

“a  metropolitan  network  configuration  can  attach  1000  TV  receivers  to  a  network  node  (through 
fiber  feeder  plants).  With  100,000  TV  receivers  tuned  to  a  channel  at  any  time,  a  multicast  tree 
may  have  100  leaves. 
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(address  fields  in  the  header  of  packets  flowing  through  various  LANs  are  shown) 


Figure  17:  Multicasting  across  interconnection  to  IP  LANs 


address  addr  associated  with  the  channel  to  a  LLC  multicast  address  mjaddrx  of 
hosts  connected  to  X  and  a  IP  level  ‘group  address’  HGy  of  hosts  connected  to  Y . 
This  mapping  may  be  represented  as: 


addr  — >  {  {jpddx,  (NET_MCAST,  [mjiddrx,  •  •  •)))> 

(pJdy,  (NET_MCAST,  [HGy,  •  •  •)))  }, 

where  p-idx  and  pJdy  are  the  ports  through  which  G  activates  the  LLC  layer  func¬ 
tions  of  LAN  X  and  the  IP  layer  functions  of  LAN  Y  respectively,  and  NET_MCAST 
is  a  flag  indicating  the  availability  of  ‘native  multicast’  facility  in  the  backbone  net¬ 
work  or  otherwise.  With  this  type  of  binding  in  G,  each  packet  received  over  X  with 
addr  as  its  label  is  forwarded  over  Y  at  the  ‘host  group’  address  HGy  using  the  IP 
multicast  protocol  available  within  Y  (the  latter  may  possibly  use  the  underlying 
LAN  broadcast  facility).  At  a  destination,  a  packet  arriving  in  the  IP  layer  at  HGy 
is  passed  on  to  the  MCL  residing  above  for  delivery  at  various  destinations  connected 
to  Y.  See  Figure  17. 

Since  the  IP  LAN  Y  may  be  viewed  as  a  system  of  interconnected  LANs  in  itself, 
another  instantiation  of  MCL  may  be  interposed  beneath  the  IP  layer  but  above  the 
LLC  layer  of  Y.  With  this  splicing  of  MCL  functions  into  Y,  the  IP  ‘host  group’ 
address  HGy  may  be  bound  to  a  logical  address  addr'  for  multicasting  packets  within 
Y  using  the  URT  model  (i.e.,  HGy  appears  as  a  UTL  address  in  U).  So  Y  forms  a 
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separate  multicast  domain,  with  the  mapping  between  addr'  and  HGy  done  by  the 
MCL  functions  at  nodes  in  this  domain. 

Thus  an  implementation  of  our  multicast  model  extending  across  LANs  X  and  Y 
consists  of  both  guest  layering  and  splicing  of  MCL  functions,  represented  as: 

addr  {  (pJdjc,  (NETAdCAST,  {rrijaddrx,  •  •  •))), 

(pJdy,  (NETAICAST,  {{HCy  ->  addr'), . . .)))  }. 

This  may  be  desirable  when  multipoint-to-multipoint  communication  support  needs 
to  be  provided  within  the  IP  LAN  Y  as  weU.  As  can  be  seen,  the  URT  model  can 
be  recursively  applied  at  various  levels  in  a  LAN  interconnection  architecture,  with 
each  level  of  recursion  mapping  to  nodes  connected  at  this  level  of  addressing. 

7.4  Implementation  strategies  for  SMDS  networks 

The  network  providing  the  SMDS  may  consist  of  one  or  more  MAN  Switching  Sys¬ 
tems  (MSS)  interconnected  with  one  another  across  a  wide  area  and/or  metropolitan 
area.  An  MSS  can  be  a  high  speed  data  switching  node  or  a  high  speed  LAN/MAN, 
such  as  FDDI  and  DQDB.  The  MSSs  and  the  interconnection  between  them  consti¬ 
tute  the  backbone  network. 

A  user  sees  SMDS  as  providing  a  ‘connection-less’  data  service.  So  each  data  frame 
excheinged  across  the  service  interface  carries  the  fuU  source  and  destination  address 
in  its  header.  The  SMDS  protocol  requires  the  individual  address  of  a  source  entity 
eind  a  group  address  for  destination  entities  (based  on  E.164  ISDN  numbering)  in 
each  SMDS  frame.  This  entity  level  addressing  is  at  a  higher  level  than  our  logical 
addressing  of  multicast  cheinnels.  So  a  sublayer  in  the  SMDS-network  interface  (SNI) 
needs  to  establish  the  mapping  between  these  two  levels  of  addressing. 

The  protocol  architecture  in  [27]  suggests  a  frjunework  for  intercoimecting  the  MSSs 
to  export  the  required  data  service  to  subscribers.  We  adopt  this  architecture  to 
embed  the  URT  model  into  the  SMDS  network  for  extending  its  multicast  capa¬ 
bilities.  The  architecture  consists  of  three  layers  of  functions:  Network  Service 
and  Control  (NSC)  layer  that  maps  SMDS  access  requests  to  operations  on  multi¬ 
cast  channels.  Routing  and  Relaying  (RR)  layer  that  provides  a  subnet-independent 
realization  of  channel  operations  with  appropriate  protocols,  and  Component  Net¬ 
work  Convergence  (CNC)  layer  that  elevates  the  MSS  specific  functions  to  a  uniform 
level  for  use  by  the  RR  layer.  Thus  the  NSC  layer  implements  the  SMDS  interface 
to  multicast  channels,  while  the  RR  and  CNC  layers  provide  an  implementation  of 
multicast  control  functions.  Accordingly,  the  URT  architecture  needs  to  be  grcifted 
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at  the  NSC-RR  layer  interface  of  the  SMDS  network  architecture,  with  the  MCL  and 
UXL  functions  embedded  into  the  RR  layer  and  NSC  layer  respectively;  the  CNC 
layer  corresponds  to  an  adaptation  layer  that  is  interposed  between  the  MCL  and 
BNL. 

To  map  a  SMDS  level  group  address  g_nm  of  destinations  to  logical  addresses  for 
use  by  the  underlying  RR  and  CNC  layers,  a  NSC  entity  maintains  two  types  of 
information: 

1.  gjnm  ->  {entjoddr}  to  bind  gjnm  to  SMDS  level  addresses  {entJiddr}  of 
entities  attached  to  the  local  SNI; 

2.  gjim  addr  to  bind  g.nm  to  a  transport  level  logical  address  addr  for  mul¬ 
ticasting. 

An  entity  U  that  wishes  to  send  and/or  receive  data  over  gjnm  interacts  with  its  NSC 
entity  across  the  SNI  along  the  control  plane  to  include  its  SMDS  level  address  in 
the  binding  information  (1).  When  U  does  not  wish  to  send  and/or  receive  any  more 
data,  it  interacts  with  the  NSC  to  remove  its  address  from  the  binding  information 
(1).  The  binding  given  by  (2)  can  either  be  static  whereby  addr  can  be  derived  from 
the  TiamiTig  structure  used  for  g.nm  or  be  dynamic  whereby  addr  may  be  generated 
from  a  pool  of  logical  addresses  maintained  by  the  NSC  layer. 

Each  data  frame  exchanged  across  the  SNI  for  multicasting  includes,  in  its  header, 
the  individual  address  of  the  source  and  the  group  address  of  the  destinations.  So  a 
NSC  entity  receiving  a  frame  F  across  the  local  SNI  for  sending  to  destinations  at 
group  address  gjnm  extracts  addr  from  the  binding  information  (2)  and  sends  F  to 
the  RR  layer  to  multicast  F  to  the  peer  NSC  entities  at  address  addr.  The  RR  layer 
prepends  addr  to  the  header  and  passes  it  down  to  the  CNC  layer  for  subnet-specific 
processing  of  the  route  information  generated  from  addr  and  dispatching  F  through 
the  component  subnets  towards  destinations.  See  Figure  18  as  an  illustration.  When 
a  peer  NSC  entity  receives  F  from  the  RR  layer,  it  uses  the  gjnm  carried  in  the  header 
of  F  to  extract  {entjaddr}  from  the  binding  information  (1)  and  delivers  F  across 
the  local  SNI  to  all  the  listed  SMDS  entities.  The  source  address  is  not  used  for 
sending /receiving  F,  but  may  be  used  by  the  SMDS  level  protocols  that  generate 
and  consume  F. 

The  aforementioned  approach  to  realize  SMDS  aligns  well  with  the  established  ap¬ 
proaches  to  LAN-MAN  interconnections  [28]. 

We  believe  that  other  multicast  architectures,  viz.,  SSRT,  CBT  and  PIM,  can  also 
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SMDS  access  at 


SMDS  access  at 


I  g— pro  I  addr  |  fn^d«lr(l)| 


y  ntn  addr  ni_addr<2)| 


I  t_Pm  addr  m_addr(3i 


(address  fields  In  the  header  of  packets  flowing  through  various  LANs  are  shown) 

Erobedding  our  multicast  model  on  SMDS  network  realized  on  top  of  LANs  (say.  LAN_I.LAN__a  and  LAN_3) 

Figure  18:  Overlaying  URT-based  multicast  model  on  SMDS  networks 
be  likewise  realized  on  interconnected  LANs  and  SMDS  networks®. 

8  Development  of  end-system  support  mechanisms 


This  section  deals  with  providing  the  mechanisms  for  displaying  multiple  video  win¬ 
dows  eind  supporting  other  application  devices  on  a  workstation.  The  formulation 
of  end-system  mechanisms  was  merely  to  demonstrate  the  feasibility  of  multicast 
application  implementations  eind  to  offer  an  evolutionary  path  towards  such  imple¬ 
mentations. 

The  work  in  this  category  pertains  to  the  design  of:  i)  logiced  address  based  ‘device 
grouping’  mechanism  for  merging/splitting  of  data  streams  in  a  workstation,  and 
ii)  node  software  structure  for  multicast  transport  and/or  generation/ delivery  of  data 
units,  as  described  below. 

‘Consider,  say,  a  subtree  of  the  ‘core’-rooted  tree  with  the  ‘core’  at  node  T,  spanning  the  nodes 
Assume  that  the  subtree  has  a  bidirectional  path  segment  between  x  and  y,  and  a  unidi¬ 
rectional  path  segment  from  x  to  z.  It  is  possible  that  this  subtree  resides  on  a  distinct  subnetwork 
that  internally  employs  another  instance  of  the  CBT  architecture,  wherein  x  and  y  act  as  source 
entities  sending  their  data  each  towards  a  ‘core’  node,  say,  T',  for  onward  distribution  to  destina¬ 
tion  entities  y,z  and  x,z  respectively  over  a  tree  rooted  at  T',  using  the  native  routing  protocols 
supported  in  this  subnetwork. 
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Flow  of  data  across  modules  in  end-system 


Grpb:  Graphics  imaging  derict 
Spk:  Speaker 
Cm:  Video  camera 
Disp:  Video  display 
Mie  Microphone 
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Figrore  19:  Illustration  of  feeder  plant  mechanisnis 
8.1  Grouping  of  application-level  devices 

A  workstation  mimicks  an  access  feeder  plant  in  a  large  network  of  subscriber  ter¬ 
minals.  A  feeder  plant  maps  the  various  subscriber  terminals,  viz.,  devices,  that 
participate  in  an  application  onto  a  single  ‘logical  device’  for  the  purpose  of  pre¬ 
senting/fielding  data  to/from  the  underlying  multicast  network.  This  is  achieved  by 
logical  address  based  grouping  of  physical  devices.  See  Figure  19. 

The  logical  address  based  grouping  of  devices  in  a  feeder  plant  allows  end-to-end 
multiplexing  of  data  streams  generated  by  various  devices  that  participate  in  a  given 
application.  This  allows  the  QOS  management 

for  the  multiplexed  data  streams  in  the  following  forms: 


•  Estimating  the  data  rates  of  combined  streams  from  that  of  the  component 
streams; 

•  Handling  of  delay  and  loss  tolerance  attributes  by  stream-specific  scheduling 
of  data  tramsport  in  end-systems. 


Developing  specific  QOS  management  policies  is  itself  outside  the  scope  of  the  con¬ 
tract  with  Rome  Laboratory. 


With  the  use  of  logical  address  based  device  grouping,  the  network  access  interface 
allows  addition  zuid  deletion  of  streeims  to  an  on-going  data  flow  under  a  given  logical 
address.  Formulation  of  primitives  for  use  in  feeder  plants  is  itself  outside  the  scope 
of  this  project. 

8.2  Workstation  software  for  multicast  transport 

A  generalized  structure  of  node  software  to  allow  the  multicast  forwarding  of  data 
packets  —  both  video  and  non- video  data  —  has  been  designed  and  implemented  on 
SUN/Solaris  workstations  (see  Figure  20).  The  software  structure  basicedly  uses  a 
shared  packet  memory  between  the  network  receiver,  source  device,  network  trans¬ 
mitter  and  destination  device  modules.  The  main  ideas  in  the  design  are: 

•  Elimination  of  data  copying  from  the  address  space  of  receiver /source  modules 
to  that  of  the  transmitter/destination  module  by  placing  data  packets  in  the 
shared  memory; 

•  Employing  less  expensive  inter-module  synchronization  mechanisms  in  the  form 
of: 

Software-implemented  mutual  exclusion  and  ordering  among  the  per-packet 
processing  of  various  modules; 

Allowing  a  high  degree  of  concurrency  among  executions  of  various  modtdes 
during  packet  processing; 

We  employed  a  ‘boimded  birffer’  based  synchronization  mechanism. 

The  above  aspects  are  in  general  employed  in  implementations  of  high  speed  network 
software. 

8.3  Connecting  application  devices 

This  pertains  to  the  distribution  of  data  packets  from  various  source  devices  (such  as 
video  cameras  and  microphones)  attached  to  workstations  over  the  multicast  network 
to  destination  devices  (such  as  video  displays  and  speakers)  on  selected  workstations. 
From  the  network  perspective,  the  application  devices  in  a  workstation  acting  as  a 
node  appecir  as  connected  to  the  data  transport  modules  through  pseudo-ports  that 
have  distinct  names  and  are  assignable  as  distinct  entries  in  the  network  routing 
table  along  with  real  network  ports  in  the  node.  This  allows  a  uniform  treatment  of 
data  movement  to/from  the  network  and  across  the  application-network  interface. 
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■i  ■■■  Data  transfer  to/from  packet  memory  Multicast  data  distribution  ports 

-  -  -  >  Inter-module  control  and  data  flow  . Access  to  synchronization  variables 

Figure  20:  Multicast  end-system  software  modules  in  a  workstation 

The  software  incorporating  this  structure  assigns  distinct  end-to-end  addresses  for 
various  devices  which  can  be  used  to  index  to  appropriate  portions  of  packet  memory 
and  the  associated  information  elements.  The  software  heindling  application  device 
modules  then  consists  of  generic  stub  interface  2uid  a  device-specific  packet  handler. 
The  stub  interface  deals  primarily  with: 

•  Mapping  of  device  level  addresses  to  control  information  elements  and  packet 
memory; 

•  Synchronization  of  device  access  to  shEured  packet  memory  and  control  infor¬ 
mation  elements  (such  as  pointers  to  the  stEirt  and  final  slots  in  a  ‘bounded 
buffer’),  with  the  network  receiver  and  transmitter  modules. 

Note  that  the  use  of  generic  transport  level  stubs  is  a  standard  method  for  connecting 
a  variety  of  devices  to  any  imderlying  network. 

The  node  softwEure  incorporating  the  inter-module  synchronization  procedures  and 
transport  level  stubs  has  been  implemented  on  the  SUN  workstations.  Care  has  also 
been  taken  to  isolate  backbone-network  specifics  from  the  software  structure,  which 
allows  adopting  the  same  softwEire  for  both  LANs  and  ATM  networks  with  minimum 
changes  in  functionsdity. 

The  end-to-end  delivery  performance  of  the  node  software  was  measured  on  both 
10  mbps  Ethernet  LANs  and  155  mbps  ATM  networks.  We  achieved  a  throughput 
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rate  of  about  7  mbps  over  UDP/IP/Ethernet  (where  a  packet  was  repeatedly  sent 
over  multiple  UDP  paths  to  realize  the  multicast),  about  8.5  mbps  over  ‘IP  multi¬ 
cast ’/Ethernet,  and  about  12  mbps  on  a  network  of  Fore  ATM  switches.  See  [29]  for 
the  details  of  performance  engineering  techniques  employed  in  the  node  software.  We 
did  not,  however,  embark  on  implementations  aimed  at  maximizing  the  throughput 
rate  and  providing  end-system  level  QOS  support,  since  these  are  outside  the  scope 
of  the  project  contract  with  Rome  Laboratory. 
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9  Technical  deliverables 


The  concrete  deliverables  were  categorized  under  the  various  project  activities,  as 
described  in  sections  3-8.  Detailed  description  of  these  deliverables  may  be  found  in 
the  various  technical  reports  submitted  to  Rome  Laboratory  POC  (‘point  of  contact’) 
during  veirious  phases  of  the  project. 

9.1  Study  of  multicast  network  architectures 

A  new  architecture  that  employs  ‘unrooted  tree’-based  multicast  channels  was  de¬ 
signed  in  this  project.  As  part  of  this  activity,  the  following  phrases  were  completed: 

1.  A  flow  &  QOS  based  cost  model  consisting  of  metrics  for  comparing  different 
multicast  architectures; 

2.  Results  on  bandwidth  gains  achievable  in  various  architectures; 

3.  Analysis  of  the  interactions  between  multicast  routing  algorithms  and  network 
architectures. 

See  [13,  14,  15]  for  the  details  on  how  the  cost  metrics  are  derived  and  estimated 
and  on  the  experimental  measurements  of  bandwidth  consumptions. 

9.2  Design  of  multicast  routing  control  protocols 

A  canonical  protocol  model  was  developed  that  allows  flow  &  QOS  specifications  to 
be  trainscribed  onto  network  internal  mecheinisms.  The  latter  manifest  in  the  form  of 
identifying  the  functional  elements  in  the  network  and  defining  the  message  space  and 
information  structures  for  use  by  multicast  router  nodes.  Algorithmic  techniques  for 
decentralized  resource  allocation  were  formtdated,  eind  then  evaluated  by  simulation. 
See  [21,  22]  for  details  of  the  protocol  model  and  its  evEiluation  studies. 

9.3  Design  of  signaling  system  overlays  on  ATM  networks 

Strategies  for  overlaying  the  routing  control  protocol  on  ATM  networks  were  defined 
and  implemented  on  the  testbed  consisting  of  Fore  and  GTE  ATM  switches.  PVC- 
based  techniques  for  the  embedding  of  various  multicast  architectures  (viz.,  SSRT, 
CRT,  PIM  and  URT)  were  identified  and  eveduated.  Details  of  these  strategies  and 
the  evaluation  results  may  be  found  partly  in  [12,  21]. 
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9.4  Interconnection  of  heterogeneous  backbone  networks 

Strategies  for  realizing  a  global  multicast  over  interconnected  heterogeneous  networks 
were  formulated,  and  then  evaluated  on  interconnected  LAN  and  SMDS  backbone 
network  architectures.  These  strategies  were  based  on  associating  a  global  logical 
address  to  each  multicast  channel  and  then  binding  this  address  into  the  underlying 
native  routing  system  of  the  backbone  network.  Details  of  these  strategies  may  be 
foimd  in  [12]. 

9.5  End-system  software  on  workstations 

Structuring  techniques  for  the  end-system  modules,  based  on  logical  grouping  of 
application  devices,  were  formulated  and  evaluated  on  SUN-sparc-5  workstations. 
Also,  performance  engineering  techniques  to  maximize  the  end-to-end  throughput 
rate  were  studied.  Experimental  results  collected  as  part  of  this  activity  and  analysis 
of  these  results  may  be  foimd  in  [29]. 

9.6  Software  demonstration 

A  multicast  application  involving  the  distribution  of  video,  audio  and  graphics  data 
was  demonstrated  on  top  of  the  ATM-based  NYNET  between  Syracuse  University 
anH  Rome  Laboratory.  The  demonstration  was  presented  to  the  Rome  Laboratory 
technical  staff  in  the  1st  week  of  August  1996.  The  demonstration  evidenced,  in 
part,  a  successful  deployment  of  the  network  mechamisms  developed  in  this  project. 

The  aforementioned  deliverables  serve  to  fulfill  the  work  items  stipulated  in  the 
Statement  of  Work  attached  to  the  contract  with  Rome  Laboratory.  For  interested 
readers,  the  technical  reports  may  be  obtaiined  from  the  Rome  Laboratory  POC. 

10  Project  contributions  to  Air  Force  research  mission 

The  subject  category  of  Distributed  Information  Environment  under  which 
this  project  was  carried  out  deals  with  ‘information  coimectivity’  among  large  ‘in¬ 
formation  repositories’  using  high  speed  networks.  For  example,  Icirge  scale  strategic 
and  tactical  information  (e.g.,  terrain  information  about  military  installations  £uid 
movements)  may  need  to  be  distributed  as  imaging  data  across  different  Air  Force 
Centers  for  dissemination  purposes.  As  another  example,  business  executives  of  a 
company  or  field  commanders  in  a  battlefield  may  engage  in  a  teleconference  session, 
involving  video,  audio  and  graphics  data,  to  coordinate  their  activities.  Our  project 
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on  transport  level  connectivity  in  networks  may  be  viewed  as  providing  a  ‘flexible 
communication  backplane’  among  ‘information  repositories’  to  allow  such  large  scale 
information  transfers.  Also,  the  project  will  allow  smooth  development  of  computer 
systems  for  information  movement  and  dissemination  at  higher  levels  of  ‘information 
architectures’. 
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11  Future  works 


As  the  project  work  evolved  and  matured,  quite  a  number  of  topics  were  identified 
that  can  be  candidates  for  future  work.  These  are: 

1.  Incorporation  of  ‘receiver-initiated’  style  resource  control  protocols  into  a  generic 
signaling  system 

What  type  of  end-to-end  protocol  support  is  required  to  allow  ‘receiver- 
initiated’  style  protocols  in  the  network,  has  been  a  topic  of  debate  in 
the  Internet  community.  Many  RFCs  have  emerged  in  the  past  2-3  years, 
but  no  consensus  has  yet  been  reached  on  a  single  set  of  reservation  mech¬ 
anisms  that  may  satisfy  the  needs  of  a  vast  majority  of  applications. 

2.  Integration  of  flow  management  in  ATM  networks 

What  model  of  ATM  level  network  connectivity  is  required  in  order  to  smoothly 
integrate  flow  management  procedures  onto  the  native  QOS  support  mech¬ 
anisms  ?  This  problem  has  attracted  the  attention  of  many  research  or¬ 
ganizations  (see  [23,  24],  for  instance). 

3.  Flow  aggregation  strategies  for  network  connections 

While  there  is  a  general  agreement  in  the  research  community  that  substantial 
savings  in  communication  resources  is  possible  by  shsiring  a  network  path 
across  multiple  data  streams,  there  has  not  yet  been  any  agreed  set  of 
mechanisms  for  aggregating  these  data  flows  into  a  single  composite  flow 
without  compromising  one  or  more  of  the  transport  functionalities.  For 
instance,  when  a  delay  sensitive  stream  (such  as  video)  is  merged  with  a 
delay  insensitive  stream  (such  as  text),  the  question  that  arises  is:  what 
is  the  delay  sensitiveness  of  the  composite  stream  ?  Is  it  the  minimum  of 
the  two  sensitivity  values  (whereupon  the  text  stream  gets  a  ‘free  ride’) 
or  the  maYirmiTn  of  the  two  values  (whereupon  the  video  stream  ‘suffers’) 
?  The  RFC  [30]  sheds  some  light  into  these  questions. 

4.  Interconnection  of  ‘multicast  islands’ 

As  networks  increase  in  size  (such  as  the  exponential  growth  of  the  Inter¬ 
net),  different  regions  of  the  network  supporting  different  types  of  routing 
protocols  becomes  a  major  impediment  to  interconnecting  them  for  data 
distribution  purposes.  The  evolution  of  ‘Mbone’  is  an  example  of  a  solu¬ 
tion  to  this  problem  [31].  Though  the  use  of  ‘point-to-point  tuimels’  to 
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interconnect  the  different  ‘IP  midticast’  regions  is  a  start,  it  by  no  mpans 
is  a  systematic  solution.  We  have  been  nurturing  an  idea  of  ‘multi-point 
tunnels’  using  logical  addresses  as  a  generic  solution  to  the  problem. 

The  list  of  aforementioned  topic  areas  of  future  works  is  by  no  means  exhaustive. 

An  overall  technology  question  in  this  context  is:  whether  ‘standardization  of 

network  subsystems’  promotes  the  growth  and  evolution  of  networks,  or  is  it  a  ‘bot¬ 
tleneck’  to  the  whole  process  of  network  evolution  itself  ?  A  more  appropriate  stance 
may  be  to  standardize  the  procedures  for  intercoimecting  the  network  subsystems, 
but  not  the  subsystems  themselves. 

12  Scientific  contributions 

The  research-oriented  nature  of  the  project  work  undertaken  in  this  contract  has 
spin-offs  in  many  directions  of  basic  and  applied  areas  of  Computing  and  Commu¬ 
nication  disciplines.  We  categorize  them  in  four  different  topics. 

Network  Engineering; 

The  project  work  exposed  a  clear-cut  separation  of  the  ‘control  plane’  and  ‘data 
plane’  functions  in  the  network  architecture.  This  allows  focusing  on  the  ‘control’ 
functions  without  intruding  into  the  ‘data  flow’  related  functions,  and  vice  versa  — 
at  least  from  a  network  designer’s  perspective.  The  functional  separation  aligns  with 
the  evolving  architectures  for  B-ISDNs  and  the  Internet. 

Software  Engineering; 

We  resorted  to  an  ‘object-oriented  structuring’  of  the  multicast  transport  system  to 
realize  the  imderlying  ‘programmable  network’  theme.  To  exemplify,  we  designed  a 
canonical  set  of  routing  control  protocols  that  allow  ‘plug-n-play’  of  different  types 
of  multicast  architectures.  We  adopted  a  similar  ‘plug-n-play’  approach  to  support¬ 
ing  a  variety  of  application  devices  by  mapping  them  to  a  single  instance  of  logical 
devices.  We  believe  that  the  ‘object-oriented’  approach  is  necessary  in  the  design  of 
any  large  networking  system  with  complex  requirements. 

Distributed  algorithms; 

The  management  of  decentralized  information  structures  at  router  nodes  is  basi¬ 
cally  a  distributed  edgorithm  problem.  In  this  exposition,  the  problem  specifically 
meinifests  as  finding  cycle-free  routes  for  a  multicast  channel  (‘safety’  property)  and 
guaranteed  determination  of  routes  (‘liveness’  property).  The  ‘safety’  and  ‘liveness’ 
requirements  need  to  be  ensured  in  the  presence  of  simultaneous  join/leave  of  users  to 
a  multicast  channel.  For  this  purpose,  ‘concurrency  control’  techniques  well-studied 
in  distributed  computing  can  be  employed. 
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Complexity  analysis  of  routing  algorithms; 

Determiniiig  3  cost  optimal  multicast  path  constitutes  the  sterner  tree  problem; 
which  has  been  shown  to  be  NP-complete  by  Combinatorial  Mathematics  researchers. 
So  many  heuristics-based  approximation  algorithms  have  been  proposed  by  the  ‘net¬ 
work  routing’  community.  In  fact,  the  ‘incrementally  cost  optimal’  and  ‘globally 
cost  optimal’  algorithms  that  we  studied  in  this  project  are  cases  of  approximation 
algorithms.  With  ‘path  sharing  across  multi-source  flows’  becoming  an  additional 
input  parameter  to  cost-based  routing  algorithms,  their  computational  complexity 
becomes  an  interesting  research  problem  in  the  area  of  Combinatorial  Computing. 

The  above  expositions  open  up  interesting  avenues  of  fundamental  research  and/ or 
technology  innovations. 
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